Modern computer systems have become increasingly modular to allow for cost-effective expansion or upgrading of the systems' capabilities. Typically, a computer system comprises a “host” device that contains the core computing hardware that that the operating system (OS) runs on, and “peripheral” device(s) that expand the functions and features of the hardware of the host device. The peripheral device is connected to the host device through a communications interface, such as a Universal Serial Bus (USB), a Serial AT Attachment (SATA) bus, a Small Computer System Interface (SCSI) bus, or the like. For many peripheral devices, an intermediary manages the communication between the peripheral device and the host device. For example, in the case of a SATA-connected peripheral device, a Host Bus Adapter (HBA) operating under the Advanced Host Controller Interface (AHCI) is used to manage the communication link between the peripheral device and the host device.
FIG. 1 shows a block diagram of a Peripheral Device 110 connected to a Host Device 101 with a Host Bus Adapter 103. As shown in FIG. 1, the HBA 103 acts as an intermediary between the Peripheral Device 110 and the Host Device 101, isolating the Peripheral Device 110 from the Host Device 101 such that a fault or device failure at the Peripheral Device 110 will not propagate to the Host Device 101. Because the HBA 103 isolates the Peripheral Device 110 from the Host Device 101, the HBA 103 also allows for easy system maintenance of the Peripheral Device 110, including for example, updating the firmware of the peripheral device, physically replacing a defective peripheral device with a new device, and so forth, without interrupting the operation of the Host Device 101. This is critical in many enterprise and consumer applications where host system downtime is undesirable or unacceptable.
FIG. 2 shows a flowchart of method steps 200 for upgrading the firmware of a peripheral device with an HBA, according to the prior art. At step 202, the host device transfers the new firmware for the peripheral device to the HBA, which in turn passes the new firmware to the peripheral device in step 204. After the new firmware is received by the peripheral device, the HBA isolates the peripheral device from the host device in step 206. Any attempts by the host device to access the peripheral device while the peripheral device is shut down in step 208 and restarted in step 210, which may result in a host device error or complete system failure, will be instead intercepted by the HBA. In step 212, the new firmware is initialized on the peripheral device and the peripheral device is ready to resume operation in step 214 after the HBA re-establishes the connection between the peripheral and host devices. As shown and described in FIG. 2, the HBA allows for a host-safe upgrade of a peripheral device with minimal interruption to the host device operation.
While the HBA provides a number of benefits to the operation of the peripheral device, there are serious drawbacks as well. As shown in FIG. 1, because information passes through the HBA 103 on its way to the Peripheral Device 110 from the Host Device 101, and vice-versa, the HBA 103 introduces latency into the communication path between the Peripheral Device 110 and the Host Device 101. This latency limits the data I/O throughput and speed of the communication between the Peripheral Device 110 and the Host Device 101. Moreover, the HBA 103 is typically implemented in hardware, which increases power consumption and takes up physical space in the Host Device 101. As peripheral devices improve in performance and complexity, and as both host and peripheral devices move to lower-power operation, the drawbacks of the HBA begin to outweigh the benefits, and there has been a shift to remove the HBA from the equation and directly connect the peripheral device to the host device, such as is done via a Peripheral Component Interconnect Express (PCIe) bus.
Removing the HBA also means losing the benefits the HBA provided, including isolating the peripheral device from the host device during a firmware upgrade of the peripheral device to avoid a host device error or complete system failure, as previously described in connection with FIG. 2. One prior art method to avoid a host access to the peripheral device during the shutdown and restart stages of a peripheral device firmware upgrade process is to upgrade the firmware of the peripheral device from the Basic Input/Output System (BIOS) of the host device.
However, upgrading the peripheral device firmware through the BIOS during the BIOS initialization phase of the host device's boot process precludes the host device from running its OS, limiting the functionality of the host device until the peripheral device is done upgrading its firmware and the OS eventually boots. This method is, therefore, particularly unsuitable for a number of applications with a larger number of peripheral devices, such as a storage server where the entire server and all storage drives must be shut down in order to upgrade the firmware of a single storage drive. Moreover, even if there is only a single peripheral device, upgrading the peripheral device firmware through the BIOS is a time-consuming process and may be unfamiliar to the vast majority of casual computer users.
Another prior art method is to power-cycle the host device and peripheral device to upgrade the firmware, as the host device will not be able to access the peripheral device when the host device is powered down, and upon powering back up, the peripheral device will be initialized with the new firmware. However, power-cycling is also undesirable in many circumstances as it increases the down-time of the host device and inconveniences the user as the user is unable to perform any operations with the host device during the power-cycle.
There is, therefore, an unmet demand for a host-safe method of upgrading the firmware of a PCIe device from the OS of the host device while minimizing any interruption to the normal operation of the host device.